Ein kurzer Überblick über die Geschichte der Anwendungsbereitstellung

Apps zu schreiben ist toll. Wenn wir das doch nur tun könnten, anstatt uns mit dem ganzen Prozess herumzuschlagen, sie zum Laufen zu bringen, oder? Ich sage oft, dass Apps wie Flugzeuge sind: Wenn sie erst mal in der Luft sind, ist die Wahrscheinlichkeit groß, dass sie reibungslos weiterlaufen, sofern man die App richtig gebaut hat. Probleme gibt es meist beim Start und bei der Landung – auch bekannt als Deployment.

In diesem Blogbeitrag tauche ich kurz in die Geschichte der App-Bereitstellung ein und schaue mir an, was sich verändert hat, was gut funktioniert hat und was auf diesem Weg nicht so toll war. 

Ein kurzer Rückblick auf die Geschichte der Anwendungsbereitstellung

1. Traditionelle Bereitstellung (Ende der 1990er bis Anfang der 2000er Jahre)

• Methode: Manuelle Uploads per File Transfer Protocol (FTP) auf Server. Webmaster entwickelten die Anwendung lokal und übertrugen sie dann manuell auf einen Produktionsserver.
• Tools: Standard-FTP-Clients wie FileZilla oder WS_FTP, unter anderem.

Heute wärst du schockiert, wenn du wüsstest, welche riesigen Systeme auf diese Weise bereitgestellt wurden, und du würdest es wahrscheinlich für verrückt halten – aber es hat auch Spaß gemacht und war spannend! Du hattest etwas zu ändern. Du hast auf das Symbol deines Lieblings-FTP-Clients doppelgeklickt (ja, wir haben Windows benutzt). Du navigiertest zu einer Datei. Doppelklick. Etwas ändern. Speichern. Voilà, Änderung übernommen. Wir haben nicht so viele Frameworks verwendet. Also hattest du wahrscheinlich irgendwo eine riesige PHP-Datei. Und deine Änderung war lokal begrenzt. Und wenn etwas kaputtging? Na ja, dann hast du einfach nochmal doppelgeklickt und das korrigiert. Bei Zykluszeiten von Sekunden war das kein Problem. Naja, bis es eines Tages doch eines wurde.

Oft genug lief deine App auf einem einzigen Server, der ausschließlich für diesen Zweck vorgesehen war. Darauf lief die Datenbank, die du brauchst, oder wenn du etwas ressourcenintensiveres betriebst, hattest du wahrscheinlich einen separaten Server für die Datenbank – was wir als mehrschichtige Bereitstellungen bezeichneten. Und normalerweise kümmerte sich jemand anderes darum (der Datenbankadministrator).

1998 gab es bei Apache bereits sogenannte virtuelle Hosts, die es ermöglichten, mehrere Websites auf demselben Rechner zu hosten, was dazu führte, dass die Leute immer mehr Anwendungen auf denselben Server packten. Wenn du also eine Datei im falschen Verzeichnis geändert hast … na ja.

Zu dieser Zeit hast du vielleicht schon mit echten Profis zusammengearbeitet und warst auf El Reg und Slashdot unterwegs, sodass du bereits einen Anschein von Aufgabentrennung hattest. Wenn das der Fall war, hattest du eigentlich schon einen Testserver und hast das Ganze auf der Staging-Umgebung durchgeführt. Und dann hat irgendein Systemadministrator die Daten in der Produktivumgebung kopiert, was gut funktionierte – bis es nicht mehr funktionierte.

2. Die Einführung von Versionskontrollsystemen (VCS) (Anfang der 2000er Jahre)

• Vorgehensweise: Entwickler begannen, VCS zur Verwaltung von Code-Versionen zu nutzen. Bei der Bereitstellung wurde der neueste Code manchmal direkt auf einen Produktionsserver ausgecheckt.
• Tools: CVS und Subversion.

Mittlerweile waren die Profis noch ernsthafter geworden und wollten tatsächlich die Kontrolle über das haben, was sie bereitstellten. Und die Entwickler fingen auch an, Ordner mit Namen wie „production_v12_final_final_backup_charles_final“ zu hassen. 

Also fingen wir an, SVN zu nutzen, und etwas in der Produktivumgebung zu bringen bedeutete meist „SVN up“ – was langsam, mühsam und oft fehleranfällig war. Aber es war die seriöse Art, die Dinge anzugehen. Die Schlauen lernten, wie man Symlinks nutzt, zuerst „SVN up“ durchführt und dann in das Web-Root-Verzeichnis wechselt. Es war wie GitOps ohne das „Ops“ und mit „Pull“ statt „Push“.

Trotzdem lief alles noch auf einem Single-Base-System. Dependency hatte in dieser Zeit seine Blütezeit. Und meistens waren Staging und Produktion mittlerweile schon lange nicht mehr synchron. Das war die Zeit, in der „Auf meinem Rechner funktioniert es“ zum geflügelten Wort wurde.

3. Shared Hosting und Control Panels (2000er Jahre)

• Vorgehensweise: Der Aufstieg des Shared Hosting machte es Privatpersonen und kleinen Unternehmen leicht, Webanwendungen zu hosten. Control Panels wie cPanel ermöglichten es den Nutzern, Hosting-Einstellungen zu verwalten und Anwendungen bereitzustellen.
• Tools: cPanel, Plesk, DirectAdmin.

Du würdest staunen, wie viel Zeug immer noch so läuft – man geht auf eine Webseite und kann aus einer Reihe von bereitstellbaren Vorlagen für verschiedene Apps auswählen (meist PHP, später aber viel mehr). Und hier passierte etwas Interessantes. Die Bereitstellung von Anwendungen wurde so viel einfacher. Ein Klick. 

Wie sich jedoch herausstellte, erschwert dies die Wartung der Anwendungen umso mehr. Wenn die Bereitstellung einfach, die Aktualisierung aber schwierig ist, ist das nicht gerade ideal. In der Regel ermöglichten diese Tools nicht nur die Bearbeitung per FTP, sondern stellten auch einen Web-Client zur Verfügung, sodass man gar nicht wissen musste, wie man eine Verbindung zu FTP herstellt.

4. Dedizierte Server und Virtual Private Server (VPS) (Mitte der 2000er Jahre)

• Vorgehensweise: Als Webanwendungen immer komplexer wurden, ging der Trend zu dedizierten Servern und VPS, um mehr Kontrolle und Ressourcen zu erhalten. So konnten Entwickler die Servereinstellungen an die Anforderungen ihrer Anwendungen anpassen.
• Tools: VMware, Xen und später KVM.

Die Virtualisierung hatte enorme Auswirkungen – plötzlich konnten wir Anwendungen von der Hardware trennen. Jetzt konnte man tatsächlich ein Maschinen-Image erstellen und dieses anstelle der Anwendung bereitstellen. 

Dieses Thema wird viel später in Form von Containern wieder auftauchen. Noch wichtiger war, dass man nun unterschiedliche Basen nutzen konnte. Aber das Erstellen von Images war eine komplexe Angelegenheit. Die Bereitstellung dauerte lange. Einige nutzten die neuen Tools, um neue Arbeitsweisen einzuführen. Andere behandelten die VM-basierten Maschinen weiterhin als etwas, für das sie FTP oder SVN nutzten. Mit denselben Ergebnissen.

5. Automatisierte Bereitstellung und Continuous Integration (CI) (Ende der 2000er bis Anfang der 2010er Jahre)

• Methode: Im Softwareentwicklungszyklus wurden automatisierte Deployment-Tools eingeführt, mit denen Code automatisch getestet und in der Produktivumgebung bereitgestellt werden konnte.
• Tools: Jenkins, Bamboo, Capistrano und Fabric.

Irgendwann hatten Softwareentwickler wie ich die Auseinandersetzungen mit den Systemadministratoren wirklich satt. Wir wurden schlecht behandelt. Und wir konnten programmieren. 

Also beschlossen wir, das Problem einfach wegzuprogrammieren. Das nennen wir bis heute DevOps. Es gab hauptsächlich zwei Varianten davon:

1. Ein Programm, das auf deinem Rechner lief und zuvor manuelle Vorgänge automatisierte (wie FTP, SVN-Upload oder das Umschalten eines Symlinks).
2. Programme, die auf den Servern liefen und im Grunde dasselbe taten.

Die Server gehörten zwar immer noch den Systemadministratoren, aber 2006 war EC2 bereits ein fester Begriff. Als Entwickler konnte man tatsächlich Zugriff auf eine laufende Maschine erhalten, ohne um Erlaubnis fragen zu müssen. Doch die Denkweise hatte sich noch nicht geändert. Und Entwickler mit wenig Sicherheitsschulung wurden in den meisten Fällen schnell (P)owned. 

Dennoch: Wenn eure Systemadministratoren damals modern genug waren, erlaubten sie euch allmählich, direkt zu deployen. Zumindest in die Staging-Umgebung. Denn das waren auch die Jahre des Dreigespanns: Dev-Staging-Prod. Wir waren automatisiert genug, um (unter großen Mühen) alle drei zu warten. Was besser war als Staging-Prod. Dennoch driftete das Staging ab, und Dev befand sich fast immer in verschiedenen Stadien der Fehlfunktion.

6. Platform-as-a-Service (PaaS) (Anfang der 2010er Jahre)

• Methode: Plattformen, die die Infrastruktur abstrahierten, sodass sich Entwickler auf das Programmieren konzentrieren konnten. Anwendungen konnten auf diese Plattformen hochgeladen werden, die sich dann um die Serverkonfiguration, die Skalierung und die Bereitstellung kümmerten.
• Tools: Heroku, Google App Engine, Microsoft Azure App Service und Platform.sh.

Das ist die Phase, über die wir am liebsten sprechen, weil wir selbst ein PaaS-Anbieter sind. Und auch wenn wir gerne über uns selbst reden würden, müssen wir unseren Vorgängern Respekt zollen. 

Zu diesem Zeitpunkt hatten wir bereits die Freiheit des direkten Deploys und die Umständlichkeit der kontinuierlichen Integration kennengelernt. Die meisten von uns, die sich voll und ganz daran gewöhnt hatten, wie hässlich Computer sind und dass jede Software fehlerhaft ist, akzeptierten dies als Teil der Kosten, die das Geschäft mit sich bringt. Nur dass in diesen Jahren noch etwas anderes passierte: Ruby und Ruby on Rails. Ein Game-Changer mit einem ganz eigenen Sinn für Ästhetik. Ruby-Leute legten mehr Wert auf Schönheit und Einfachheit als auf alles andere. 

Damals befanden wir uns auf dem Höhepunkt des Moore’schen Gesetzes – Computer wurden immer schneller und selbst dein langsames Programm würde mit der Zeit schneller werden, warum also nicht stattdessen auf seine Lesbarkeit und Schönheit setzen? 

Tests wurden in der Ruby-Welt nicht als „notwendiges Übel, weil die Sprache ein unsicheres Durcheinander ist“ angesehen, sondern als Beweis dafür, dass man das System in einfachen Begriffen durchdacht hat. Um es mit den Worten des französischen Dichters Boileau zu sagen: „Was wir gut begreifen, drückt sich klar aus, und die Worte dafür kommen leicht.“ 

Ein weiterer wichtiger Faktor war Git, das schnell genug auf den Markt kam und SVN verdrängte.

Es gibt einen riesigen Unterschied in der Absicht zwischen `svn up` und `git push`. Aber das Wichtigste war, dass Git das Erstellen von Branches kostengünstig und schnell machte. Die Leute von Heroku, mit ihrer Liebe zur Einfachheit und zur ruby-Ästhetik, sagten im Grunde: Server und cloud-Server sind jetzt „Vieh“. Was Systemadministratoren für uns tun, kann und sollte automatisiert werden. Wir werden alles vereinfachen und dir eine einzige Laufzeitumgebung und eine einzige Datenbank zur Verfügung stellen. Immer gleich; kein Ausweichen von den Vorgaben. Auf diese Weise kannst du `git push` ausführen und dein Programm läuft auf einem öffentlich zugänglichen Server. 

Das hätte das Ende der Geschichte sein können, das letzte Wort, aber Heroku wurde schon früh von Salesforce aufgekauft. Das soll keineswegs heißen, dass Salesforce ein schlechter Verwalter war – sie haben im Laufe der Zeit sogar ein paar Laufzeitumgebungen hinzugefügt –, aber der Dienst blieb im Großen und Ganzen so, wie er war, und ignorierte alles um ihn herum, was in den nächsten 15 Jahren kommen würde. Und das Versäumnis von Heroku, mit der Zeit zu gehen, machte die Leute misstrauisch gegenüber der Idee. 

Die PaaS hätte das sein können, was Entwicklern die Freiheit gab, sich ohne unnötigen Aufwand und Bürokratie auszudrücken, aber innerhalb der vorgegebenen Grenzen zu bleiben, fühlt sich nicht so an.

Aber selbst wenn man sich an die Vorgaben hielt, ließen Heroku und seine minderwertigen Nachahmer von Google und AWS (AppEngine und Beanstalk) dem Entwickler (und mittlerweile dem DevOps-Team) noch eine ganze Menge Ärger. Es konnte zwar in der Produktivumgebung arbeiten, doch Continuous Integration, Entwicklungs-Staging und alles, was über die einzelne Laufzeitumgebung und die zugehörige verwaltete Datenbank hinausging, wurden nur als Nebensache behandelt. Dabei handelte es sich um den Großteil dessen, was jedes ausgereifte Softwareunternehmen benötigt. 

Darauf kommen wir noch zurück, wenn wir über Upsun Cloud sprechen, aber das ist im Wesentlichen die Wette, auf die wir gesetzt haben: Dass man den gesamten Prozess in einem einzigen Dienst zusammenfassen kann – denn eine echte Platform-as-a-Service muss eine Plattform für den gesamten Continuous-Delivery-Zyklus sein.

7. Containerisierung und Microservices (Mitte der 2010er Jahre)

• Methode: Anwendungen wurden zunehmend als Sammlungen lose gekoppelter Microservices entwickelt. Container kapselten diese Dienste und stellten sicher, dass sie über alle für ihre Ausführung erforderlichen Abhängigkeiten verfügten.
• Tools: Docker, Kubernetes, Docker Swarm und Platform.sh.

Um beim Thema PaaS zu bleiben: Zwei der Probleme, die die frühen PaaS-Systeme nicht lösten, waren die lokale Ausführung von Software und die Ausführung von Microservices. Microservices konnten damals nicht lokal ausgeführt werden, da dies im Grunde unmöglich war.

Bei den frühen PaaS-Systemen ging es um Vereinfachung, und wie gesagt, sie konzentrierten sich auf den spezifischen Anwendungsfall eines einzelnen Monolithen mit einer einzigen verwalteten Datenbank. 

8. Infrastructure-as-Code (IaC) und Serverless (Ende der 2010er Jahre)

• Methode:
  • IaC: Die Einrichtung und Konfiguration der Infrastruktur wurde zunehmend als Programmierung behandelt, was konsistente und reproduzierbare Umgebungen ermöglichte.
  • Serverless: Entwickler schrieben Funktionen, die als Reaktion auf Ereignisse ausgeführt wurden, ohne sich um die zugrunde liegenden Server kümmern zu müssen.
• Tools: AWS Lambda, Google Cloud Functions, Azure Functions, Terraform, Ansible, oh, und Platform.sh.

9. Progressive Web Apps (PWAs) und JAMstack (Ende der 2010er bis Anfang der 2020er Jahre)

• Ansatz: Der Trend ging hin zu clientseitig gerenderten Anwendungen und der Nutzung von APIs für Backend-Vorgänge. Bei der Bereitstellung wurden meist statische Dateien auf Edge-Knoten von Content-Delivery-Netzwerken (CDN) hochgeladen.
• Tools: Netlify, Vercel, Cloudflare Pages und – du hast’s erraten – Platform.sh.

10. Edge-Computing (2020er Jahre)

• Methode: Verlagerung von Rechenleistung und Datenspeicherung näher an den Ort, an dem sie benötigt werden, um Reaktionszeiten zu verbessern und Bandbreite zu sparen.
• Tools: AWS Wavelength, Cloudflare Workers, Akamai Edge Workers und Upsun Cloud.

Der große Überblick: Der Trend zur Automatisierung

Im Laufe der Jahre ging der Trend in Richtung mehr Automatisierung, besserer Abstraktion und einer verbesserten Entwicklererfahrung. Während sich das Web und die damit verbundenen Technologien weiterentwickeln, werden sich auch die Bereitstellungsmethoden und -tools weiter verändern, um neuen Herausforderungen und Chancen gerecht zu werden.

In diesem Beitrag sind vor allem zwei Trends wichtig, die sich auf die aktuelle Entwicklung beziehen:

Der Aufstieg der Containerisierung

• Schon vor Kubernetes wurde die Bereitstellungslandschaft durch Docker verändert, das die Container-Technologie populär machte. Container sorgten für eine einheitliche Umgebung von der Entwicklung bis zur Produktivumgebung und stellten sicher, dass die Ausrede „Auf meinem Rechner funktioniert es“ der Vergangenheit angehörte. Doch als Container immer mehr an Bedeutung gewannen, wuchs der Bedarf, sie effizient zu verwalten, zu orchestrieren und zu skalieren – insbesondere bei groß angelegten Anwendungen.

Das Aufkommen von Kubernetes (Mitte der 2010er Jahre)

• Kubernetes wurde 2014 von Google eingeführt und basierte auf den Erfahrungen mit Borg, einem internen Cluster-Managementsystem. Kubernetes löste die Herausforderungen der Container-Orchestrierung, -Skalierung und -Verwaltung.
• Kubernetes war anfangs nicht der einzige Akteur. Es gab andere Tools und Plattformen wie Docker Swarm und Apache Mesos, die im Bereich der Container-Orchestrierung um die Aufmerksamkeit der Branche wetteiferten. Kubernetes gewann jedoch dank seines robusten Funktionsumfangs, seiner aktiven Community und der Unterstützung durch Branchenriesen rasch an Popularität, was dazu führte, dass es zum De-facto-Standard für die Container-Orchestrierung wurde.

Während Kubernetes als Tool zur Orchestrierung von Containern begann, reicht sein Einfluss mittlerweile weit darüber hinaus und hat die Bereitstellungslandschaft grundlegend verändert. Es hat dazu beigetragen, dass sich Muster wie Microservices durchsetzen konnten, neue Paradigmen wie GitOps beflügelt und ein riesiges Ökosystem aus Tools und Erweiterungen ins Leben gerufen.

Wo Upsun Cloud ins Spiel kommt

Upsun Cloud versucht, die gesamte oben beschriebene Entwicklung zusammenzufassen und das, was funktioniert, in eine übersichtliche Self-Service-Lösung zu bündeln:

1. Vereinfachung und Abstraktion

• Einheitliches Toolset: Eine moderne PaaS-Plattform abstrahiert die Komplexität der zugrunde liegenden Infrastruktur, sodass sich Entwickler auf das Programmieren und das Bereitstellen von Anwendungen konzentrieren können. Anstatt mit mehreren Tools für Container-Orchestrierung, Skalierung, Protokollierung, Überwachung usw. jonglieren zu müssen, erhalten Entwickler eine einheitliche Plattform, die diese Features von Haus aus integriert.
• Optimierte Arbeitsabläufe: Entwickler können die Infrastruktur und die Dienste, die ihre Anwendung benötigt, mithilfe von Konfigurationsdateien definieren. Dieser Ansatz vereinfacht und standardisiert den Bereitstellungsprozess.

2. Zukunftssicherheit und Flexibilität

• Anbieterabhängigkeit vermeiden: Viele PaaS-Lösungen, darunter auch Upsun Cloud, sind cloudunabhängig konzipiert. Das bedeutet, dass du nicht an einen bestimmten Cloud-Anbieter gebunden bist und somit die Flexibilität hast, den Anbieter zu wechseln oder sogar mehrere Anbieter zu nutzen, ohne dass dafür wesentliche Änderungen am Code erforderlich sind.
• Anpassung an Trends: Moderne PaaS-Lösungen können neue Tools schnell integrieren oder sich an veränderte Best Practices anpassen, sodass Entwickler stets Zugriff auf die neuesten Methoden und Technologien haben, ohne den Aufwand einer manuellen Integration.

3. Konsistenz über alle Umgebungen hinweg

Upsun Cloud ermöglicht es Entwicklern beispielsweise, ihre Produktionsumgebung für Entwicklung, Tests oder Staging zu klonen. So wird sichergestellt, dass sich die Anwendung in allen Phasen einheitlich verhält, was das Risiko unerwarteter Verhaltensweisen in der Produktivumgebung aufgrund von Umgebungsunterschieden verringert.

4. Integrierte CI/CD

Viele moderne PaaS-Plattformen verfügen über integrierte Pipelines für Continuous Integration und Continuous Deployment, die sicherstellen, dass Programme nahtlos getestet und bereitgestellt werden. Diese Integration reduziert den Bedarf an Tools von Drittanbietern und optimiert den Prozess von der Entwicklung bis zur Bereitstellung.

5. Skalierbarkeit und performance

Dank automatischer Skalierungsfeatures können PaaS-Lösungen schwankende Zugriffslasten ohne manuelles Eingreifen bewältigen. Sie können Ressourcen nach Bedarf zuweisen und so für optimale performance und Kosteneffizienz sorgen.

6. Sicherheit

Moderne PaaS-Lösungen verfügen oft über integrierte Sicherheitsfeatures, darunter automatische Patches, sichere Netzwerkkonfigurationen und Compliance-Zertifizierungen. Diese integrierte Sicherheit bedeutet weniger manuelle Konfiguration und weniger Tools von Drittanbietern, wodurch potenzielle Fehlerquellen reduziert werden.

7. Wirtschaftlichkeit

Da der Bedarf an mehreren Tools und Diensten sinkt, kann PaaS zu Kosteneinsparungen führen. Unternehmen müssen nicht für jedes einzelne Tool Fachwissen aufbauen, und die Betriebskosten lassen sich dank der Skaleneffekte, die PaaS-Anbieter erzielen, senken.

Zusammenfassend lässt sich sagen, dass die Entwicklung der Tools unsere Sichtweise auf Anwendungsbereitstellung und Infrastruktur verändert hat – und jedes dieser Tools bringt seine eigenen Komplexitäten mit sich. Moderne PaaS-Lösungen wie Upsun Cloud sind eine Antwort auf den Bedarf an einfacheren, einheitlichen und zukunftssicheren Bereitstellungsmethoden. Da sich die Technologie ständig weiterentwickelt, ist die Fähigkeit, mit minimalem Aufwand agil und anpassungsfähig zu bleiben, ein entscheidender Vorteil, der PaaS für viele Unternehmen zu einer attraktiven Wahl macht.

Möchtest du es mal ausprobieren? Starte noch heute deine kostenlose Testphase. 

Schau dir dieses Video an